Refer to this link for build results (access rights to CI server needed):
http://jenkins.jsk.imi.i.u-tokyo.ac.jp:8080/job/hrpsys-qnx/2394/

Build Log
last 10 lines

[...truncated 3482 lines...]
    at org.jenkinsci.plugins.ghprb.GhprbRepository.createCommitStatus(GhprbRepository.java:122)
    at org.jenkinsci.plugins.ghprb.GhprbBuilds.onCompleted(GhprbBuilds.java:118)
    at org.jenkinsci.plugins.ghprb.GhprbBuildListener.onCompleted(GhprbBuildListener.java:27)
    at org.jenkinsci.plugins.ghprb.GhprbBuildListener.onCompleted(GhprbBuildListener.java:12)
    at hudson.model.listeners.RunListener.fireCompleted(RunListener.java:201)
    at hudson.model.Run.execute(Run.java:1786)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
    at hudson.model.ResourceController.execute(ResourceController.java:98)
    at hudson.model.Executor.run(Executor.java:408)

Test FAILed.

これって何も実害はないと思いますが、なんでこうしないといけないのか、という所が気持ち悪いですね。

正直、謎なところですね。

他に影響しないようにコードを書きましたが、自分でも気持ちが悪い書き方になっています。

PPAでのopenrtmのバージョンはいくつなんでしょうか？

2015年10月21日水曜日、Yosuke [email protected]さんは書きました:

正直、謎なところですね。

他に影響しないようにコードを書きましたが、自分でも気持ちが悪い書き方になっています。

—
Reply to this email directly or view it on GitHub
#858 (comment)
.

◉ Kei Okada

PPAのopenrtmはここのブランチから毎晩最新のものを取ってきてビルドがかかっています。

http://svn.openrtm.org/OpenRTM-aist/branches/RELENG_1_1/

1.1.2+アルファ、という感じです。

PPAのhrpsys-baseは -Wbpackage=hrpsys -Wbinline のオプションをつけてスタブを生成しているので、その影響かな、とも思っています。このオプションをつけるとidl内で定義された定数が参照できるようになるのですが、findObjectで帰ってきたオブジェクトがすでにnarrowがかかっている（？）みたいな状態にもなっています。

IPython上でfindObjectするとこんな感じで帰ってきます。

In [8]: rtm.findObject('sh', 'rtc')
Out[8]: <hrpsys.OpenRTM._objref_DataFlowComponent instance at 0x7f448ac09050>

オブジェクトのtypecodeからインスタンス型を推定して違う型にnarrowしようとすると、たとえそれが抽象クラスであってもエラーを出して警告してくれる、ような機能が入っているのかな、と推察しています。

なるほど。
ネームサーバから取ってきた時点でもうDataFlowComponentになっているというのが謎ですね。

2015年10月21日 11:14 Yosuke Matsusaka [email protected]:

IPython上でfindObjectするとこんな感じで帰ってきます。

In [8]: rtm.findObject('sh', 'rtc')
Out[8]: <hrpsys.OpenRTM._objref_DataFlowComponent instance at 0x7f448ac09050>

オブジェクトのtypecodeからインスタンス型を推定して違う型にnarrowしようとすると、たとえそれが抽象クラスであってもエラーを出して警告してくれる、ような機能が入っているのかな、と推察しています。

—
Reply to this email directly or view it on GitHub
#858 (comment)
.

以下のように書いたらエラーが出ませんでした。

rtc = RTcomponent(obj._unchecked_narrow(RTC.RTObject))

この方がきれいかもしれませんね。

omniorbpyの実装まで見てみようかな、とも思いもしたのですが、オブジェクトのtypecodeからインスタンス型が推定できる場合は勝手にnarrowしてくれる、という、ある意味で余計な親切機能が働いているという推定で間違いないと思います（import RTCする前にnsにresolveすると普通のオブジェクトが帰ってきていたので）。

rtm.pyの考え方は_unchecked_narrowと同じであるという理解で良いと思うのですが、これに直す方向で良さそうでしょうか？

え〜っと、unchecked_narrowってどういうものでしょうか。

2015年10月21日 11:44 Yosuke Matsusaka [email protected]:

omniorbpyの実装まで見てみようかな、とも思いもしたのですが、オブジェクトのtypecodeからインスタンス型が推定できる場合は勝手にnarrowしてくれる、という、ある意味で余計な親切機能が働いているという推定で間違いないと思います（import
RTCする前にnsにresolveすると普通のオブジェクトが帰ってきていたので）。

rtm.pyの考え方は_unchecked_narrowと同じであるという理解で良いと思うのですが、これに直す方向で良さそうでしょうか？

—
Reply to this email directly or view it on GitHub
#858 (comment)
.

narrowするときにtypecodeをチェックしない、というnarrowのしかたです。

なので安易に使うと、narrowはできたけどあとでメンバ関数呼び出した時にfunction not foundエラーが出る状態になる可能性があります。

kind='rtc'でネームサーバにresolveかけているので、帰ってくるのはRTObjectだろう、という可能性が高い場合、あまり問題にならないはず、なのですが、どのオブジェクトも無理やりnarrowしてしまいtypecodeレベルではエラーが帰ってこないので、そこで救われている事例があった場合再考が必要です。

ちなみに、ubuntu14.04だとomniORBは4.1.6のようですが、@yosuke さんの環境はもっと新しかったりするのでしょうか。

2015年10月21日 12:03 Yosuke Matsusaka [email protected]:

narrowするときにtypecodeをチェックしない、というnarrowのしかたです。

なので安易に使うと、narrowはできたけどあとでメンバ関数呼び出した時にfunction not foundエラーが出る状態になる可能性があります。

kind='rtc'でネームサーバにresolveかけているので、帰ってくるのはRTObjectだろう、という可能性が高い場合、あまり問題にならないはず、なのですが、どのオブジェクトも無理やりnarrowしてしまいtypecodeレベルではエラーが帰ってこないので、そこで救われている事例があった場合再考が必要です。

—
Reply to this email directly or view it on GitHub
#858 (comment)
.

libomniorb4-1は4.1.6-2で、python-omniorbは3.6-1（ubuntu14.04を使っています）なので、同じ環境です。

今のところスタブ生成に-Wbpackage=hrpsys -Wbinlineオブションをつけたことによって、お節介機能が機能する条件を整えてしまった可能性が高いな、と思っています。

今の状態でもコードはやや気持ち悪い＆DataFlowComponent以外の型が出てきた場合に追加で書く必要がある、という以外は安全サイドに振った実装になっていると思うので、とりあえずこれでおいておきたいと思います（今後変な現象ありましたら私にもmentionください）。